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REMARKS 

Claims 6-12 and 14-20 are pending in the application. Claims 6, 14-15 and 18-19 are being 
amended. The amendment to claim 6 and 14 is supported by Fig. 4 and its description in 
paragraph [0046] of the patent application as published. 

All outstanding requirements will now be addressed in the order they appear in the Office 
Action mailed November 13, 2008. 

4. The Examiner is of the opinion that claim 14 as amended to recite "retrieving all data, 
according to identified parameters, from the carousel of objects" and "storing the data being 
retrieved" can be interpreted to mean that all data that have a specific PID number are 
retrieved from the carousel of objects and not necessarily all data. 

Accordingly, Applicant has amended claim 6 and claim 14 by specifying that the step of 
retrieving all data, from the carousel of objects, occurs within a single cycle 401, 410 of the 
carousel of objects. This amendment is supported by Fig. 4 and its description which reads in 
paragraph 0046 of the published patent application, as follows: 

"... the modules are retrieved from the stream one by one, as they are broadcasted... " 

"... The whole operation occurs in the time marked as 410. Only later they are 
analyzed. Thanks to that, the time needed to update the data is reduced to the 
indispensable minimum and a much shorter start-up time is ensured for the 
applications operating in the receiver, in case they need an exchange of modules... " 

As defined by 401 and 410, a cycle can start anywhere in time and last until all data of the 
carousel of objects have been received without being repeated. Prior art solutions require 
more than a single cycle 409 in order to obtain dependent modules of a hierarchy. 
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With respect to claim 20, Applicant respectfully notes that the passage of "...filter for passing 
all data related to the carousel of objects ..." is not contrary to previous arguments since the 
parameters of the filter are such that all data of the carousel are passed. 

The filter is required since data of a carousel is only a fraction of data of a transport stream. 
That is the reason for setting up a filter according to given parameters. 

Moreover, in a typical DSM-CC carousel it is allowed that different modules may have 
different PID numbers assigned. Hence a filter requirement when all data of a carousel are 
concerned. As support, Applicant includes in Appendix A, pages 325-326, from Digital 
Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3, ETSI 
ES 201 812 VI. 1.2 (2006-08), Annex B (normative): Object carousel, B.4 Example of an 
Object Carousel, htt p://www.mhp.org/specs/es 20 1 8 1 2 vO 1 0 1 02p . pdf , which recites an 
example of a carousel wherein modules are identified with 3 different PID numbers PID n, 
PID n+1 and PID n+2, respectively. 

Claims Rejections - 35 USC §112 

5. Claims 15, 18, 19 stand rejected under 35 U.S.C. §112, second paragraph, as being 
allegedly indefinite for failing to particularly point out and distinctly claim the subject matter 
which Applicant regards as invention. Specifically, the Office Action states that claims 15, 
18 and 19 contain confusing language. 

Applicant has amended claims 15, 18, 19 to obviate the Examiner's rejection. 

Claims Rejections - 35 USC §102 and 35 USC §103 

6-25. Claims 6, 7, 9-12, 14, 15 and 17-19 stand rejected under 35 U.S.C. §102(e) as being 
allegedly anticipated by Stalker, U.S. Patent Publication No. 2002/0091816, claims 14 and 
16-19 stand rejected under 35 U.S.C. § 102(b) as being anticipated by Metz et al, U.S. Patent 
No. 5,768,539, claims 8 and 16 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Stalker, US Patent Publication No. 2002/0091816 in view of Chari US Patent No. 
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6,038319, whereas claims 15 and 20 stand rejected under 35 U.S.C. §103(a) as being 
unpatentable over Metz et al, U.S. Patent No. 5,768,539 in view of Stalker, US Patent 
Publication No. 2002/0091816. 

Applicant respectfully disagrees that Metz, col. 38, line 33-35, discloses reassembling the 
modules only after all modules of the application file have been downloaded. Metz merely 
defines that an application is reassembled when all modules have been downloaded. It does 
not refer to a method of modules download and reassembling. The cited passage may only 
apply to the step of "obtaining content of the modules" as claimed. 

Additionally, in order to clarify any doubts and strengthen clarity, Applicant has amended 
claim 14 and claim 1 by specifying that the step of retrieving all data, from the carousel of 
objects, occurs within a single cycle 401, 410 of the carousel of objects (vide supra). This is 
supported by Fig. 4 and its description which reads in paragraph 0046 of the patent 
application as published. 

Therefore, the invention achieves the effect of rapid retrieval of all modules and the effect of 
avoiding waiting for multiple cycles. 

Accordingly, Applicant believes that the claims as amended are not anticipated by Stalker 
and Metz and are in condition for allowance. 



THIS SECTION INTENTIONALLY LEFT BLANK 
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CONCLUSION 

In view of the foregoing amendments and remarks, Applicant submits that the pending 
claims are in condition for allowance. Early and favorable reconsideration is respectfully 
solicited. Should an extension of time be required, Applicants hereby petition for same and 
requests that the extension fee and any other fee required for timely consideration of this 
submission only be charged to Deposit Account No. 503182. 

Respectfully Submitted, 

Customer Number: 33,794 

/Matthias Scholl/ 

Dr. Matthias Scholl, Esq. 
Reg. No. 54,947 
Attorney of Record 

Date: February 5, 2009 
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B.4 Example of an Object Carousel (informative) 

The figure below illustrates an object carousel that is distributed over three elementary streams belonging to the same 
service. 




Figure B.2 : Example carousel 



The DownloadServerlnitiate (DSI) message is carried on the first elementary stream. It contains the object reference that 
points to the ServiceGateway. The tap with the BIOP_DELIVERY_PARA_USE points to a Downloadlnfolndication 
(DII) message that provides the information about the module and the location where the module is being broadcasted. In 
the example, the ServiceGateway object is in the module number 1 that is earned on the second elementary stream 
(indicated by a BIOP_OBJECT_USE tap structure in the DII message). 

The ServiceGateway object is a root directory that, in this example, references three subdirectories. Taps with BIOP_ 
DELIVERY_PAPvA_USE are used in the object references of the subdirectories to provide links to the modules via the 
Downloadlnfolndication (DII) message. The two first subdirectories "dirl " and "dir2" are referenced in the DII message 
that is carried in the first elementary stream. The third subdirectory is referenced in the DII message carried in the third 
elementary stream. 

In this example, the two first elementary streams carry the messages of one logical data carousel while the third 
elementary stream carries the messages of another logical data carousel. All these belong to the same object carousel. In 
the example, the third elementary stream contains the objects in the "dir3" subdirectory and the objects in the "dirl" and 
"dir2" subdirectories are distributed over the first and second elementary stream. 

It is important to note that the third elementary stream may originate from a completely separate source than the first two 
elementary streams. The directory hierarchy and objects contained in the third elementary stream are "mounted" in the 
root directory by providing the "dir3" directory entry with the appropriate location information. 
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This type of structure could be used, for example, in a national information service that contains some regional parts. The 
common national parts could be carried in this example case on the two first elementary streams that are distributed 
unmodified in the whole country. The regional parts are carried in the third elementary stream that is locally inserted at 
each region. From the application's point of view, the common national parts are in the "dirl" and "dir2" subdirectories 
while the regional parts are in the "dir3" subdirectory. 

Another example where this type of structure could be used is if the service contains multiple independent applications. 
In this case, each application could be placed in its own subdirectory and these subdirectories might be carried as 
separate data carousels on different elementary streams. 

B.5 Caching 

This section describes the constraints that an MHP terminal compliant with this specification shall implement when 
caching any content from the object carousel in the memory of the MHP terminal. Caching is optional for the MHP 
terminal, but if implemented shall conform to the constraints set in this section. 

B.5.1 Determining file version 

There is no version number directly related to files (or other BIOP messages), the closest association is the 
module Version in the DII that references the module that contains the BIOP message. Therefore, to ensure that a file is up 
to date the MHP terminal must determine that the module Version for the appropriate module is current and reacquire if 
necessary. The circumstances under which this checking is required are defined by the transparency level as specified in 
the following section. 

B.5.2 Transparency levels of caching 

The definition of transparency levels describes the behaviour that the MHP terminal shall implement \\ hen the content in 
the object carousel is changing. The transparency level determines how certain the MHP terminal is required to be about 
the validity of the content when returning the content to the application. The object carousel provides a mechanism for 
determining version changes of the content by monitoring the DII messages. 

Validity of content is specified here in terms of the version number of the module that is broadcast in the DII message. 
The contents of an object as cached in the memory of the MHP terminal are defined to be valid at a certain point in time 
when the version number of the module in the cache matches the version number of the module as signalled in the DII 
message describing that module as it was last broadcast. Note that the definition is based on the DII message that was last 
broadcast and it may be that the MHP terminal was not filtering for this message at that time and did not receive it. 

From the MHP terminal point of view, the transparency level indicates the constraints that the terminal needs to 
implement for monitoring the DII messages. 

The broadcaster can indicate the appropriate transparency level that shall be applied for a given piece of content by using 
a descriptor associated with a module in the DII message (see "Caching priority descriptor" on page 298). In the absence 
of this descriptor from a module, the transparent caching is the default level. 

B.5.2. 1 Transparent caching 

The transparent caching is a caching level that ensures that the application can not practically notice a difference in the 
validity of the returned content between an implementation that caches content and an implementation that does not 
cache any content. Naturally, an implementation that caches the content will return it to the application faster. 

When returning content from the cache to the application, the MHP terminal shall ensure that the version number of the 
cached content matches the version number indicated in the current DII message describing that module. Once a DII has 
been received it can be assumed that it is current at least for 500 ms and after that period until receiving the next instance 
of the relevant DII. If filtering for that DII has not resumed by the end of this period, the state of that DII is to be 
considered unknown until it is received again. 

Therefore, terminals must not return transparently cached data if it has waited more than half a second between receiving 
the relevant DII and starting to filter for that DII again. If the terminal does not resume filtering within the 500ms grace 
period, it must download the relevant DII again when it wishes to use that DII to check cache validity. 

The choice of 500 ms is based on the normal timing uncertainty in data delivery through the broadcast chain and is 
independent of the repetition rate of the DII messages. 
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